SingletonSupplier is not singleton if null is returned on first supplier call #35380
Conversation
spring-projects-issues
added
the
status: waiting-for-triage
nosan
force-pushed
the
35369
branch
2 times, most recently
from
a722667 to
a596879
Compare
| private static final Object NULL = new Object() { | ||
|
|
||
| @Override | ||
| public String toString() { |
There was a problem hiding this comment.
It seems that overriding this method is not necessary, what's the purpose?
There was a problem hiding this comment.
The reason that the method is overridden isn't for functionality but for debugging purposes.
When overridden:
Previously, SingletonSupplier stored "null" in singletonInstance when the supplied instance was "null". On subsequent get() calls, this was treated as "uninitialized" and triggered another attempt to obtain an instance. This commit ensures that a "null" returned from the instanceSupplier or defaultSupplier is handled correctly, so that subsequent calls to get() return "null" consistently instead of repeatedly invoking the supplier. Signed-off-by: Dmytro Nosan <[email protected]>
|
|
||
| reset(dataSource); | ||
| given(dataSource.getConnection()).willReturn(connection); | ||
| translator = new SQLErrorCodeSQLExceptionTranslator(dataSource); |
| public @Nullable T get() { | ||
| T instance = this.singletonInstance; | ||
| if (instance == null) { | ||
| if (!this.initialized) { |
There was a problem hiding this comment.
as initialized has no external use, is this variable really necessary? cant we directly use this.singletonInstance == null or add a function->
public boolean isInitialized() {
return Objects.nonNull(this.singletonInstance);
}
There was a problem hiding this comment.
Using this.singletonInstance == null can't tell the difference between "not initialized yet" and "initialized but supplier returned null." Since the supplier can return null, a separate flag needs to be used to record that initialization was attempted. Otherwise, the supplier will keep getting re-invoked.
See #35369 for more details.
4 participants
See #35369